<?php
/**
 * <https://y.st./>
 * Copyright © 2018 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'Late payments',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<img src="/img/CC_BY-SA_4.0/y.st./weblog/2018/12/14.jpg" alt="I think the rain is clearing up." class="framed-centred-image" width="649" height="480"/>
<section id="drudgery">
	<h2>Drudgery</h2>
	<p>
		The school wrote to me yesterday, saying I could now pay tuition fees for my current term.
		Not this morning, less than twenty-four hours later, they wrote telling me fees (of an undisclosed type) overdue.
		Seriously?
		You&apos;re giving me less than twenty-four hours to pay?
		You do realise it takes longer than that for my tuition cheques to make it through the postal system, right?
		It could be other fees, but I don&apos;t have anything else I owe them.
		I wrote back asking what they were talking about, and my advisor intercepted the message, responding that it&apos;d been an error in the system and to ignore it.
		Due to some recent issues, I wasn&apos;t sure ignoring it completely was safe, as they recently tried to charge me for something I never asked for.
		My advisor had said that was an error as well, and to also ignore that.
		It could be that that was left unfixed though, so they were hounding me for those fees, as like I said, the letter didn&apos;t even tell me what fees they thought were overdue.
		However, with my advisor&apos;s letter in hand, I figured if something came up, I could prove I tried to figure out what they wanted from me and had been told not to worry about it.
		It probably wouldn&apos;t get me out of missing a term because this school is so screwy, but it&apos;d keep me out of trouble.
		Later in the day though, the payments office wrote back confirming that it&apos;d been an error, and to ignore the overdue notice.
		Well okay then.
		That was odd.
	</p>
	<p>
		I was too busy yesterday trying to catch up on stuff to get to the credit union, and I&apos;m still scrambling from the aftermath of that today.
		I had to get that discussion post below written up and submitted, which took just about all of today&apos;s time.
		I needed to get it in today though; I&apos;ve a schedule to keep.
		I think I can get the cheque picked up tomorrow, though I&apos;m not sure I&apos;ll make it to the post office in time to get that sent just yet, due to them having shorter hours on Saturday.
		It might have to send it on Monday, instead.
	</p>
	<p>
		My discussion post for the day:
	</p>
	<blockquote>
		<h3>Not just Web languages</h3>
		<p>
			The most obvious difference between $a[PHP] and JavaScript is that while they both tend to run in a client/server Web environment, one is typically reserved for server-side scripting and one typically reserved for client-side scripting.
			$a[PHP] isn&apos;t restricted to use on the Web though.
			For example, it&apos;s perfectly capable of powering command line scripts.
			I use it a lot for command line scripts because it&apos;s easier to work with than basic Bash, but it also lacks the bad attitude of Python.
			I&apos;m told Perl might be a better alternative, though I haven&apos;t had time to learn Perl yet myself.
			As for JavaScript, I think a project called Node.js makes JavaScript run outside Web browsers, making it also possible to script non-Web-related things in JavaScript too.
		</p>
		<h3>Web things: client- versus server-side scripting</h3>
		<p>
			While we&apos;re on the topic of the Web though, we might as well discuss client- versus server-side scripting.
			Which should you use?
			In most cases, if scripts are needed at all, they should be on the server side.
			You know what your server is running.
			You only need your scripts to function on that one system with that one setup.
			Alternatively, if you need the scripts to run on multiple machines, those machines are all under your control.
			You can install the needed software and run the needed configuration.
		</p>
		<p>
			Compare that to client-side scripting.
			Users can and often do disable JavaScript in their Web browsers for any number of perfectly-valid reasons.
			For that reason, you should <strong>*never*</strong> use client-side scripting for vital functionality that&apos;s possible to achieve without it.
			There is <strong>*no excuse*</strong>, for example, to use JavaScript to provide basic navigation features to your Website with no fallback option for when JavaScript is disabled.
			Some <strong>*poorly-designed*</strong> websites cannot be easily navigated if JavaScript is disabled.
			No well-designed website ever does this; navigation without JavaScript reliance is <strong>*necessarily*</strong> an element of all good designs.
		</p>
		<p>
			As a personal example that causes me trouble, we have this school&apos;s website.
			There&apos;s a bug in this site&apos;s JavaScript that causes the site to chew on my coursework.
			I&apos;ve reported it multiple times to the school, but they refuse to do anything and they claim I&apos;m the only one affected.
			I&apos;ve even tried pointing them the direction of the problem based on my own research into it, and they don&apos;t care.
			Regardless of whether I truly am the only one affected, the simple fact is that I <strong>*absolutely must*</strong> have JavaScript disabled in my Web browser when visiting this site.
			Otherwise, my coursework submissions get mangle and I have to redo them.
			Sometimes, I don&apos;t even notice until I&apos;ve submitted and it&apos;s too late.
			I notice the problem days later, when editing is no longer an option.
		</p>
		<p>
			The school&apos;s old navigation system worked just fine, as did the messaging system.
			However, the latest major update to the site&apos;s design pushed a lot of that into the JavaScript.
			I&apos;m now only able to access part of the navigation due to this poor design work, and the messaging system no longer functions for me at all.
			Again, disabling JavaScript is the only way I can make sure my coursework doesn&apos;t get mangled.
			Obviously, this is a perfectly-legitimate reason for having JavaScript disabled.
			When you&apos;re building a website, please don&apos;t do this to your users!
			They may have legitimate reasons for not using JavaScript as well.
			It&apos;s the mark of a sloppy and/or just plain <strong>*incompetent*</strong> Web developer to build vital functionality in JavaScript unnecessarily.
			Don&apos;t get me wrong, some things legitimately do require JavaScript, but almost every basic use case - such as site navigation - most certainly does not.
		</p>
		<h3>$a[PHP]</h3>
		<p>
			$a[PHP] was built to be built into $a[HTML] pages.
			This has some interesting consequences for its syntax.
			It basically starts out in a literal string output mode.
			Whatever characters are in the file are output as if you&apos;d called, for example in Java, <code>System.out.print()</code> on them.
			You must explicitly leave string-output mode using the characters <code>&lt;?php</code>.
			Re-entering text-output mode can be done using the characters <code>?&gt;</code> (Techotopia, 2016).
			This makes it easiest to have a file that begins with outputting text before it does anything else, and also makes it very easy to output large sections of text.
			You don&apos;t have to bother with the <code>echo</code> command, which is useful when you have lots of new line characters or quotation marks to deal with in the output, both of which are characteristic of $a[HTML].
			Of course, this also works for non-$a[HTML] text formats as well.
			I&apos;ve seem people use $a[PHP] to output $a[RSS], for example, and I use it for both $a[XHTML] and plain text files.
		</p>
		<p>
			This quirky feature has a small drawback as well.
			Because all files begin in text-output mode, files that aren&apos;t meant to output anything directly, such as files defining classes, functions, and constants, must begin with <code>&lt;?php</code> as their first characters to avoid accidentally outputting garbage to the page or console (depending on where $a[PHP] is being run).
		</p>
		<p>
			Our reading assignment mentions that $a[PHP] didn&apos;t have support for object classes until $a[PHP]4 (Techotopia, 2016).
			Think about that for a bit.
			The language was built with no support for classes, but now has support for them.
			The obvious implication is that $a[PHP] was a basic procedural language, but now has object-oriented components.
			If you&apos;ve worked with $a[PHP] as long as I have, you realise that $a[PHP] is partly object-oriented, but partly procedural.
			It&apos;s a strange and inconsistent amalgam.
			This same sort of thing has happened with other features of the language as well, and $a[PHP] has a number of bizarre quirks because of it.
			The language, in many ways, lacks consistency and a unified direction.
		</p>
		<p>
			Despite its issues, $a[PHP] is wildly popular.
			It powers many of the websites we use every day (Atwood, 2008).
			The simple fact is that it&apos;s an open-source tool that fits into a particular Internet niche that people need it for.
			Apache, another open source project, is the most popular Web server on the planet.
			The $a[PHP] engine has been built to couple with Apache much cleaner than any other server-side scripting engine I&apos;ve ever heard of.
			As for performance, the $a[PHP] engine must perform decently well.
			If not, how could it power Wikipedia, one of the largest websites on the planet?
			There are projects written in $a[PHP] that are known to be a bit slow and clunky, but you can program poorly in any language.
			$a[PHP] gets the job done when you use it right.
			Being an open-source project, $a[PHP] is also highly portable.
			It&apos;s been compiled to run on all major systems, as well as several lesser-known systems.
			Apache, which $a[PHP] is usually used with, has also been compiled for and made run on all major systems and several lesser-known systems.
			These are reliable projects that serve as a foundation for websites you need to build.
		</p>
		<h3>JavaScript</h3>
		<p>
			I&apos;m not as familiar with JavaScript as I am $a[PHP].
			As I said above, $a[PHP] is my go-to shell scripting language.
			Meanwhile, the only place I use JavaScript is the Web.
			Like mentioned above, keeping JavaScript to a minimum on websites is best, so I don&apos;t often have a need for JavaScript.
		</p>
		<p>
			JavaScript is an object-oriented language (Botting, n.d.).
			Unlike $a[PHP], it&apos;s not some wacky hybrid of object-orientation and procedural functionality.
			It has a pretty wide adoption, with nearly every Web browser supporting some form of it.
			However, Web browser vendors and bad Web developers alike can&apos;t resist abusing it.
			Web browser vendors tend to add features to their implementation of the language that work only with their Web browser.
			Incompetent Web developers then use these features in a long list of &quot;if this browser do that&quot; conditional statements.
			This results in very unportable code.
			If you&apos;re using a Web browser not on their list, even if your Web browser supports the JavaScript standard perfectly, their code won&apos;t work in your browser.
			This is particularly stupid on the part of the Web developers, too.
			They have to maintain each branch of this conditional, when they could instead write standards-compliant code that runs on most if not all Web browsers supporting JavaScript, and have much less code to maintain.
			JavaScript as a language is very portable.
			You can run it in nearly every Web browser.
			Code written in JavaScript can be very portable.
			However, in practice, much JavaScript code is written by incompetent people and isn&apos;t portable at all.
			That&apos;s not a fault of the language itself, but the fault of both the Web browser developers, who add non-standard things to their implementations, and incompetent Web developers, who don&apos;t write standards-compliant code themselves.
		</p>
		<p>
			A good example of this lack of standards compliance would be my credit union&apos;s website.
			If I log into my credit union&apos;s website normally, none of the JavaScript works.
			However, if I alter my <code>User-Agent:</code> string, the website&apos;s JavaScript works perfectly.
			<strong>*In the same Web browser.*</strong>
			They&apos;re sending different code to different browsers instead of sending standards-compliant code to all browsers.
			And by default, they don&apos;t send something that works with my browser, but my browser is clearly capable of running some of the code they send to other browsers.
			What makes it particularly annoying is that certain vital features don&apos;t function without the JavaScript.
			This website is horridly designed.
		</p>
		<p>
			JavaScript tends to vary in performance depending on how it&apos;s used and the conditions under which it&apos;s used.
			For example, this university&apos;s website sends a lot of $a[AJAX] requests, and not just when the page is loading.
			$a[AJAX] requests lock up the page until they complete.
			Large $a[AJAX] requests on a slow Internet connection result in the page locking up for extended periods of time.
			This is the cause of the university&apos;s website mangling my coursework; I&apos;m in the middle of typing and the page will lock up, so everything I type while the page is locked is just gone.
			This is also likely why the university can&apos;t see the error in testing, despite my pointing out exactly what&apos;s causing it: the development team is working on fast connections, and not accounting for the fact that some of us have very slow connections.
			JavaScript doesn&apos;t seem to perform as well as bare $a[HTML]/$a[XHTML] for page elements, so even if all your users have JavaScript enabled (which they probably don&apos;t), eliminating JavaScript and using $a[HTML]/$a[XHTML] and $a[CSS] instead can greatly speed your page&apos;s render time.
			Almost every time I encounter a slow Web page, it&apos;s only slow because it&apos;s bogged down by such heavy JavaScript.
			When JavaScript is used properly, which is to say not for complex computations, continuous unnecessary $a[AJAX] requests, and basic rendering functionality that belongs in $a[HTML]/$a[XHTML] and $a[CSS], it seems to perform well enough.
			JavaScript, in the context of the Web, is really only good for small enhancements to pages; never for vital page functionality.
			For example, it&apos;s perfect for making the left and right arrow keys take users to the previous and next pages of a site, provided basic links are provided for people that have JavaScript disabled.
		</p>
		<div class="APA_references">
			<h3>References:</h3>
			<p>
				Atwood, J. (2008, May 20). PHP Sucks, But It Doesn&apos;t Matter. Retrieved from <a href="https://blog.codinghorror.com/php-sucks-but-it-doesnt-matter/"><code>https://blog.codinghorror.com/php-sucks-but-it-doesnt-matter/</code></a>
			</p>
			<p>
				Botting, R. J. (n.d.). Sample:JavaScript. Retrieved from <a href="http://csci.csusb.edu/dick/samples/javascript.html"><code>http://csci.csusb.edu/dick/samples/javascript.html</code></a>
			</p>
			<p>
				Techotopia. (2016, October 27). An Overview of PHP - Techotopia. Retrieved from <a href="https://www.techotopia.com/index.php/An_Overview_of_PHP"><code>https://www.techotopia.com/index.php/An_Overview_of_PHP</code></a>
			</p>
			<p>
				Techotopia. (2016, October 27). The History of PHP - Techotopia. Retrieved from <a href="https://www.techotopia.com/index.php/The_History_of_PHP"><code>https://www.techotopia.com/index.php/The_History_of_PHP</code></a>
			</p>
		</div>
	</blockquote>
</section>
<section id="Minetest">
	<h2>Minetest</h2>
	<p>
		I figured out how I&apos;m going to match colours in ValessaE&apos;s palette to colours in my own without week&apos;s worth of brute force attempts.
		First, I&apos;ll assign a weight to each of VanessaE&apos;s colours.
		These weights will be based on the distance from absolute grey.
		I&apos;ll brute force in waves, from the highest weight to the lowest weight.
		High-weight things, which have the most distinct colours, will match with my colours first, leaving less colours for the less-distinct colours, until all the colours have been matched up.
		The results may not be as perfect as a full all-at-once brute force attack on the problem would be, but it&apos;ll certainly be a whole lot faster for the computer to find a reasonable solution.
		I think it&apos;ll work out just fine.
	</p>
</section>
END
);
